-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
std: Stabilize APIs for the 1.11.0 release #34530
Conversation
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
cc @rust-lang/libs, the deprecation of |
@alexcrichton Your comments about the fallout and unlikelihood of stabilizing |
I'm personally still confident in stabilizing the sum/product methods, but yes we're digging ourselves into a hole with The methods of This would entail killing |
e0aa055
to
71dec1b
Compare
impl Sum for $a { | ||
fn sum<I: Iterator<Item=$a>>(iter: I) -> $a { | ||
iter.fold(0, |a, b| { | ||
a.checked_add(b).expect("overflow in sum") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why always check rather than use +
with its configurable behavior?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With MIR we unfortunately don't have that luxury as whether the arithmetic is checked or not is encoded into the MIR, not generated at trans time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that relevant because libcore
is usually distributed pre-compiled? If so it’s worth a source comment at least, and maybe a doc-comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The overflow behavior is documented on the sum/product methods, and yes this is due to it being distributed as a compiled artifact.
One stability nit, otherwise r=me |
@bors: r=aturon |
📌 Commit 71dec1b has been approved by |
⌛ Testing commit 71dec1b with merge 9ef8ff8... |
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
|
71dec1b
to
7cfcb4a
Compare
@bors: r=aturon |
📌 Commit 7cfcb4a has been approved by |
⌛ Testing commit 7cfcb4a with merge f632159... |
💔 Test failed - auto-win-msvc-64-cargotest |
|
Although the set of APIs being stabilized this release is relatively small, the trains keep going! Listed below are the APIs in the standard library which have either transitioned from unstable to stable or those from unstable to deprecated. Stable * `BTreeMap::{append, split_off}` * `BTreeSet::{append, split_off}` * `Cell::get_mut` * `RefCell::get_mut` * `BinaryHeap::append` * `{f32, f64}::{to_degrees, to_radians}` - libcore stabilizations mirroring past libstd stabilizations * `Iterator::sum` * `Iterator::product` Deprecated * `{f32, f64}::next_after` * `{f32, f64}::integer_decode` * `{f32, f64}::ldexp` * `{f32, f64}::frexp` * `num::One` * `num::Zero` Added APIs (all unstable) * `iter::Sum` * `iter::Product` * `iter::Step` - a few methods were added to accomodate deprecation of One/Zero Removed APIs * `From<Range<T>> for RangeInclusive<T>` - everything about `RangeInclusive` is unstable Closes rust-lang#27739 Closes rust-lang#27752 Closes rust-lang#32526 Closes rust-lang#33444 Closes rust-lang#34152 cc rust-lang#34529 (new tracking issue)
7cfcb4a
to
3016626
Compare
@bors: r=aturon |
📌 Commit 3016626 has been approved by |
std: Stabilize APIs for the 1.11.0 release Although the set of APIs being stabilized this release is relatively small, the trains keep going! Listed below are the APIs in the standard library which have either transitioned from unstable to stable or those from unstable to deprecated. Stable * `BTreeMap::{append, split_off}` * `BTreeSet::{append, split_off}` * `Cell::get_mut` * `RefCell::get_mut` * `BinaryHeap::append` * `{f32, f64}::{to_degrees, to_radians}` - libcore stabilizations mirroring past libstd stabilizations * `Iterator::sum` * `Iterator::product` Deprecated * `{f32, f64}::next_after` * `{f32, f64}::integer_decode` * `{f32, f64}::ldexp` * `{f32, f64}::frexp` * `num::One` * `num::Zero` Added APIs (all unstable) * `iter::Sum` * `iter::Product` * `iter::Step` - a few methods were added to accomodate deprecation of One/Zero Removed APIs * `From<Range<T>> for RangeInclusive<T>` - everything about `RangeInclusive` is unstable Closes #27739 Closes #27752 Closes #32526 Closes #33444 Closes #34152 cc #34529 (new tracking issue)
Although the set of APIs being stabilized this release is relatively small, the
trains keep going! Listed below are the APIs in the standard library which have
either transitioned from unstable to stable or those from unstable to
deprecated.
Stable
BTreeMap::{append, split_off}
BTreeSet::{append, split_off}
Cell::get_mut
RefCell::get_mut
BinaryHeap::append
{f32, f64}::{to_degrees, to_radians}
- libcore stabilizations mirroring pastlibstd stabilizations
Iterator::sum
Iterator::product
Deprecated
{f32, f64}::next_after
{f32, f64}::integer_decode
{f32, f64}::ldexp
{f32, f64}::frexp
num::One
num::Zero
Added APIs (all unstable)
iter::Sum
iter::Product
iter::Step
- a few methods were added to accomodate deprecation of One/ZeroRemoved APIs
From<Range<T>> for RangeInclusive<T>
- everything aboutRangeInclusive
isunstable
Closes #27739
Closes #27752
Closes #32526
Closes #33444
Closes #34152
cc #34529 (new tracking issue)